REMARKS 

The Examiner is tlianked for the thorough examination of the present application. 
The Office Action, however, continued to reject all examined claims 1-4 and 8-32. In 
response. Applicant submits the foregoing amendments and the following remarks. 
Claims 1 and 17 are amended. No new matter Is added to the application by these 
amendments. Applicant respectfully requests reconsideration and withdrawal of the 
rejections for at least the following reasons. 

Summary of Telephone Interview 

Applicant wishes to thank Examiner Andrews for time spent with Applicant's 
representative, Thomas Hildebrandt, Reg. No. 59,303, during a telephone interview 
conducted on July 23, 2009, regarding the above-identified Office Action. During the 
interview, the rejection of claims 1 and 17 under 35 U.S.C. § 103(a) was discussed. 
Several arguments and a proposed amendment were presented. However, no 
agreement as to the allowability of the claims was reached. 

Discussion of Rejections Under 35 USC 103 

The Office Action rejected independent claims 1 and 17 under 35 U.S.C. § 
103(a) as allegedly unpatentable over the Bell Labs Technical Journal article in view of 
Mayer (US 2005/001 5499). Applicant respectfully requests reconsideration of the 
rejections in view of the foregoing amendments and the following remarks. 

Applicant still believes that the difference between SIP response and SIP request 
is arguable. Claim 1 is amended to better describe the distinctiveness. 
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The amendnnent to the step of "a Serving Call Session Control Function (S-CSCF) 
recording the SIP request message and forwarding the SIP request message to a 
second UE without checking any initial Filter Criteria and a oina through an application 
server" is based on the specification in Fig. 4b and embodiments described on page 8 
at lines 22-24: "The S-CSCF 423 forwards the SIP invite message to UE2 435 via the P- 
CSCF 431 without going through the AS 424a." As an apparent distinction from the 
prior art in Fig. 4a, the iFC is not needed and is never checl<ed in the embodiment. The 
amendment to the step of "the S-CSCF examining the SIP response message 
according to a set of response Filter Criteria (rFC) defining a set of Service Point 
Triggers (SPTs). comprising specific SIP responses triggering individual application 
sen/ices available from a service provider" is based on the specification at page 5, lines 
8-19, where the definition and use of rFC is specifically explained. 

Turning to the specific language of claim 1, claim 1, as amended, recites: 

1 . A triggering method for IP multimedia service control, 
comprising the steps of: 

a first User Equipment (UE) initializing a Session Initial Protocol 
(SIP) request message; 

a Serving Call Session Control Function (S-CSCF) recording 
the SIP request message and forwarding the SIP request message to 
a second UE without checking any Initial Filter Criteria and going 
through an application server, 

the S-CSCF receiving a SIP response message initialized by the 
second UE associated to the SIP request message; 

the S-CSCF examining the SIP response message according to 
a set of response Filter Criteria (rFC) defining a set of Service Point 
Triggers (SPTs), comprising specific SIP responses triggering 
individual application services available from a service provider, and 

re-issuing the SIP request message to the application server 
designated by the rFC If the SIP response message matches Service 
Point Triggers (SPTs) of one of the rFC; wherein the SIP response 
message Is a final response-Initialized by the second UE. 

{Emphasis added). Claim 1 patently defines over the cited art for at least the reasons 
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that the cited art fails to disclose the features emphasized above. 

As amended, claim 17 recites: 

17. An Internet Protocol (IP) multimedia subsystem, comprising: 
one or more application servers each designated by a response 
Filter Criteria (rFC), wherein the rPC defines a set of Service Point 
Triggers (SPTs) to provide a service in response to SIP response 
messages; and 

a Serving Call Session Control Function (S-CSCF), forwarding 
a Session Initial Protocol (SIP) request message initialized by a first 
User Equipment (UE) to a second UE witfiout checking any initial 
Filter Criteria and going through an application server, receiving a 
Session Initial Protocol (SIP) response message initialized by the second 
UE associated to the SIP request message, examining the SIP response 
message by a set of response Filter Criteria (rFC), and re-issuing the 
SIP request message to the application server when a Service Point 
Trigger (SPT) in a rFC that designates to the application server is 
matched by the SIP response message; wherein the SIP response 
message is a final response initialized by the second UE. 

{Emphasis added). Claim 17 patently defines over the cited art for at least the reasons 

that the cited art fails to disclose the features emphasized above. 

The Office Action cites Shaheen Fig. 1 and paragraph [0004] as teaching the first 
UE, second UE, and the SIP request message without going through an application 
server. Applicant respectfully disagrees because Shaheen is irrelevant to filter criteria 
and an application server. 

Paragraph [0004] of Shaheen states: 

[0004] FIG. 1 shows a simplified session initiation system. A user, 
UE-A 20, desires to initiate a media session with another user UE-B 40. In 
FIG. 1 , UE-A 20 is shown as "roaming" in network A 22, not its home 
network. UE-A 20 sends a SIP invite message 44i to UE-B 40 via network 
A 22. The UE-A SIP invite 44. sub. 1 indicates all the media types that it 
can support. As shown in FIG. 1 , the SIP invite 44ihas a header, global 
information, and a list of the supported media types (media 1 to media 6). 
The supported media types include information for each media, such as 
the CODEC type, stream format, stream bit rate, and communication port 
number. Under the proposed system, there are no limits on the number of 
media types that a UE can include in the SIP invite message. 
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FIG. 1 of Shaheen is reproduced below: 




The disclosure of Shaheen appears to be intended to remove unwanted traffic in 
the SIP messages. Applicant notices that this citation is nothing to do with an 
application server. Shaheen never suggests employing an rFC to examine SIP 
response messages to trigger an application server. No application server is triggered, 
nor is any application server triggered by any rFC in response to any SIP response 
message. Shaheen does not show or suggest going through any application server 
because it concerns a method that is irrelevant to the application server. Therefore, 
there is no reason to combine Shaheen with Bell Labs Technical Journal or Mayer to 
exhibit the same function as recited in claims 1 and 17. 

Next, regarding the step of "the S-CSCF examining the SIP response message 
according to a set of response Filter Criteria (rFC) defining a set of Service Point 
Triggers (SPTs), comprising specific SIP responses triggering individual application 
services available from a service provider," the Office Action states that Bell Labs 
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Technical Journal cols. 2 and 1, pages 32 and 33, lines 6-15 and 1-9 respectively teach 

the feature. 

However, the cited description discusses examination of a SIP request message 
against the filter criteria, not examination of a SIP response message. Filter criteria are 
examined one by one according to their priorities. This is irrelevant to what is 
emphasized in claims 1 and 17. In fact, the claimed embodiment attempts to skip the 
filtering of SIP request messages, and emphasizes on filtering of SIP response 
messages. The present amendment embodies the feature of skipping filtering of SIP 
request messages in the claims. 

Applicant respectfully submits that no agreement was reached in the telephone 
interview in part because the difference of a SIP request message and a SIP response 
message was not understood. According to the interview summary provided by the 
Examiner, the Examiner appears to have thought that a response message necessarily 
followed the request message and would be processed the same. Applicant will explain 
their difference in support of the patentability of such an arrangement. 

Applicant conducted an Internet search and found a document explaining the 
difference of SIP request and SIP response messages. See SIP Messages, HP-UX 
Java SIP Stack Programmer's Guide: HP-UX 1 1 i v3, available at 
http://docs.hp.com/en/5992-4080/ch01s04.html (last visited August 18, 2009); see also 
HP-UX Java SIP Stack Programmer's Guide: HP-UX 1 1 i v3, available at 
http://docs.hp.com/en/5992-4080/5992-4080.pdf (full document). According to the 
document, a SIP message has two types: request and response. The SIP request and 
SIP response messages appear to use a similar format. Both types of messages 
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consist of a start-line, one or more header fields, an empty line indicating the end of 
header fields, and an optional message-body. However, the syntax differs in character 
set and syntax specifics. The request messages are in the form of nouns, for example, 
INVITE, BYE, and so on. The response messages are always in the numerical form, for 
example, 180, 200, or 404. 

Thus, the roles of who initiates the messages are different, the syntaxes of the 
messages are different, which means the process and filtering mechanisms are 
different, and the direction of message flows are different. Furthermore, the causes for 
sending the messages are different. When in a dialog, for example, processing/filtering 
of an SIP request message may achieve certain functionalities. However, it does not 
necessarily mean that processing/filtering of a correpsonding SIP response message 
would exhibit the same effect. Applicant notes that none of the references discusses 
functionalities triggered by SPTs of the rFC for SIP response messages. In particular, 
the Bell Labs Technical Journal, at page 33, col. 1, lines 21-27, does not discuss filter 
criteria for response messages. 

Regarding the step of "re-issuing the SIP request message to the application 
server designated by the rFC if the SIP response message matches Service Point 
Triggers (SPTs) of one of the rFC; wherein the SIP response message is a final 
response initialized by the second UE" recited in claim 1, the Office Action cites Bell 
Labs Technical Journal, Fig. 9, as a rejection. The filter criteria in Bell Labs Technical 
Journal, Fig. 9, appears to be for SIP request messages from a first UE, not for SIP 
response messages from a second UE. Fundamentally, the principle of the present 
application is not taught by Bell Labs Technical Journal. 
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The Office Action cites Mayer at page 3, lines 10-17, as teacliing SIP response 
messages received by S-CSCF according to filter criteria. According to Mayer, page 3, 
lines 10-17, a SUBSCRIBE request is sent to the S-CSCF. According to Mayer, Fig. 2, 
the S-CSCF responds to the SIP SUBSCRIBE request according to event filters, and 
sends the SIP SUBSCRIBE request to a local Service Configuration Server (SCS). 
Notably, Mayer's disclosure is no nnore than a conventional SIP mechanism conforming 
to the principle as taught by Bell Labs Technical Journal. There is only one UE (Fig. 1 , 
UE 10) involved in the SIP dialog, and the SIP SUBSCRIBE request is one of the SIP 
request messages. Thus, Mayer fails to teach filter criteria for examining SIP response 
messages from a second UE, either. Furthermore, the flowchart in Mayer Fig. 2 always 
goes through the application server (which could be the local Service Configuration 
Server). Mayer does not suggest a mechanism not including the application server 
when it is unneeded. Since the emphasized feature is not taught, even a combination 
of Mayer, Shaheen with Bell Labs Technical Journal would not exhibit same function as 
claimed in our invention. Thus, the conclusion of the Office Action regarding Mayer's S- 
CSCF receiving SIP response messages is improper. 

For at least the foregoing reasons. Applicant respectfully requests withdrawal of 
the rejections of claims 1 and 17. Moreover, Applicant submits that the dependent 
claims not specifically addressed herein are allowable for the reasons discussed in 
pertinent portions associated with their independent claims 1 and 17, as well as for their 
own additional features. Applicant respectfully requests withdrawal of the rejections. 
Reconsideration of all claims is respectfully requested. 
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Should the Examiner believe that a teleconference would be helpful to expedite 
the examination of this application, the Examiner is invited to contact the undersigned. 

A credit card authorization is provided herewith to cover the fees associated with the 

accompanying RCE application and extension of time. No additional fee is believed to be 

due in connection with this submission. If, however, any fee is believed to be due, you are 

hereby authorized to charge any such fee to deposit account No. 20-0778. 

Respectfully submitted, 

/Daniel R. McClure/ 

By: 

Daniel R. McClure, Reg. No. 38,962 

Thomas, Kayden, Horstemeyer & Risley, LLP 

600 Galleria Pkwy, SE 
Suite 1500 
Atlanta, GA 30339 
770-933-9500 
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